home *** CD-ROM | disk | FTP | other *** search
- From: bs@research.att.com
- Message-ID: <199601191512.IAA09192@tijeras.scd.ucar.EDU>
- X-Original-Date: Fri, 19 Jan 96 10:11 EST
- Path: in1.uu.net!bounce-back
- Date: 19 Jan 96 17:17:09 GMT
- Approved: fjh@cs.mu.oz.au
- Organization: -
- Newsgroups: comp.std.c++
- Subject: Re: STL still in standard
- References: <4dgrb4$a2e@engnews1.Eng.Sun.COM> <4dd7on$djk@rc1.vub.ac.be>
- X-Auth: PGPMoose V1.1 PGP comp.std.c++
- iQBFAgUBMP/S2OEDnX0m9pzZAQHGyAF/W4nvd17yEop7GCHRSjxQFl0XlwYi7goK
- UhkUvEmWed5AizUedAJO2pU7IicWY+Jc
- =Lamv
-
- aishdas@haven.ios.com (Micha Berger)
-
- > Steve Clamage (clamage@Eng.Sun.COM), the Chair of X3J16, C++ Committee
- > writes::
- > : The C++ Committee has been unanimous (or nearly so) in its acceptance
- > : of STL. I do not believe there is any chance it will be dropped.
-
- I agree. The STL is here to stay, and I for one am is glad that it is.
-
- > I don't like STL because it represents an abandonment of one of C++'s
- > strengths, the tools for implementing an object oriented design.
-
- Preferring one tool for another for a particular task is not abandonment
- of other tools in a toolset. It is the proper way to use a tool set.
-
- An analogy: I'm not abandoning my fork because I prefer to use a spoon to
- eat my soup. You can design a contraption that can be used as a spoon, a
- fork, and a knife. That way, you can have a single tool rather than a
- tool set. However, that ``sporkn'' is not quite as good a fork as a fork,
- not quite as good a spoon as a spoon, ...
-
- > STL just isn't OO. It's the creation of algorythms that are not connected
- > to the data they act upon. That doesn't make STL inherently wrong, but it
- > does seem out of place in light of the number of design decisions made
- > to enable OO.
-
- In my opinion, templates is a better mechanism for creating efficient
- type-safe containers than derivation. You can build a conventional OO
- container and its associated operations on top of the STL without loss
- of efficiency or generality. The opposite is not the case for any
- inheritance-based library I have seen. For that reason alone, the STL
- is a better choice as a *standard* library.
-
- In general, please remember that OOP is not the only effective form
- of programming. Use of inheritance often leads to the most extensible,
- efficient, and general systems, but not always. Associating operations
- directly with a class as members often gives the greatest notational
- convenience, efficiency, and maintianability, but not always.
-
- STL is an example of a library where generality, elegance, and efficiency
- were best achieved through other means. Had the containers been provided
- without algorithms, programmers would have had to write their own (imagine
- C-style strings without strlen(), stdcpy(), ...). Had the algorithms not
- been generic, they would have had to be replicated (undoubtedly with many
- minor an annoying variations), or we would have had to invent a set of
- container convertion mechanisms. Had the algorithms been less general
- in their interfaces, they would not have met the needs of experts.
-
- Where needed, we regain the classical OO benefits by using objects and
- pointers to polymorphic objects as elements of containers, and by using
- the containers and algorithms in the implementation of more traditional
- hierarchies.
-
- C++ is a multi-paradigm language (see D&E); the aim is to utilize the
- various styles where appropriate.
-
- - Bjarne
-
-
- [ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
- Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
- is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
-